Enablers and Impediments for Collaborative Research in Software Testing: An Empirical Exploration

When it comes to industrial organizations, current collaboration efforts in software engineering research are very often kept in-house, depriving these organizations off the skills necessary to build independent collaborative research. The current trend, towards empirical software engineering research, requires certain standards to be established which would guide these collaborative efforts in creating a strong partnership that promotes independent, evidence-based, software engineering research. This paper examines key enabling factors for an efficient and effective industry-academia collaboration in the software testing domain. A major finding of the research was that while technology is a strong enabler to better collaboration, it must be complemented with industrial openness to disclose research results and the use of a dedicated tooling platform. We use as an example an automated test generation approach that has been developed in the last two years collaboratively with Bombardier Transportation AB in Sweden

Exploring Behaviours of RESTful APIs in an Industrial Setting

A common way of exposing functionality in contemporary systems is by providing a Web-API based on the REST API architectural guidelines. To describe REST APIs, the industry standard is currently OpenAPI-specifications. Test generation and fuzzing methods targeting OpenAPI-described REST APIs have been a very active research area in recent years. An open research challenge is to aid users in better understanding their API, in addition to finding faults and to cover all the code. In this paper, we address this challenge by proposing a set of behavioural properties, common to REST APIs, which are used to generate examples of behaviours that these APIs exhibit. These examples can be used both (i) to further the understanding of the API and (ii) as a source of automatic test cases. Our evaluation shows that our approach can generate examples deemed relevant for understanding the system and for a source of test generation by practitioners. In addition, we show that basing test generation on behavioural properties provides tests that are less dependent on the state of the system, while at the same time yielding a similar code coverage as state-of-the-art methods in REST API fuzzing in a given time limit

Factors Limiting Industrial Adoption of Test Driven Development: A Systematic Review

Test driven development (TDD) is one of the basic practices of agile software development and both academia and practitioners claim that TDD, to a certain extent, improves the quality of the code produced by developers. However, recent results suggest that this practice is not followed to the extent preferred by industry. In order to pinpoint specific obstacles limiting its industrial adoption we have conducted a systematic literature review on empirical studies explicitly focusing on TDD as well as indirectly addressing TDD. Our review has identified seven limiting factors viz., increased development time, insufficient TDD experience/knowledge, lack of upfront design, domain and tool specific issues, lack of developer skill in writing test cases, insufficient adherence to TDD protocol, and legacy code. The results of this study is of special importance to the testing community, since it outlines the direction for further detailed scientific investigations as well as highlights the requirement of guidelines to overcome these limiting factors for successful industrial adoption of TDD

Redefining the Role of Testers in Organisational Transition to Agile Methodologies

Many challenges confront companies when they change their current software development process to an agile development methodology. Those challenges could be rather difficult but one that requires considerable attention is the integration of testing with development. This is because in heavyweight processes, as in the traditional waterfall approach, testing is a phase often conducted by testers as part of a quality assurance team towards the end of the development cycle whereas in the agile methodology testing is part of a continuous development activity with no specific "tester" role defined. In this paper we consider several options for testers when an organisation transit to agile methodology, and propose a new project mentor role for them. This role aims to utilize the knowledge that testers already have in both the business domain and the development technology together with their expertise in quality practices. This role will enhance the stature of testers as well as enable the company to effectively deploy the testers in the new environment. Motivations and benefits for this role are presented in this paper together with our plan for evaluation of this proposal